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(57) ABSTRACT 

An exemplar workflow is disclosed for use in the design and 
deployment of a workflow for multi-enterprise collabora- 
tion. The computer implemented process involves allowing 
a workflow design to include at least one exemplar work- 
flow. The exemplar workflow is associated with an exemplar 
node allowing at least one activity to be parameterized over 
a plurality of nodes within a node group. The process then 
involves instantiating the workflow such that the at least one 
exemplar workflow is instantiated as a plurality of activities 
each associated with a specific node in the node group. The 
workflow is deployed by distributing the activities over the 
nodes in the node group to provide multi-enterprise collabo- 
ration. 
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EXEMPLAR WORKFLOW USED IN THE enterprise. Thus, decision support software, such as 12 

DESIGN AND DEPLOYMENT OF A TECHNOLOGIES* RHYTHM family of products, that sup- 

WORKFLOW FOR MULTI-ENTERPRISE port optimal decision making within enterprises can be 

COLLABORATION particularly important to the success of the enterprise. In 

5 general, optimal decisions are relative to the domain of the 

RELATED APPLICATIONS decision support where the domain is the extent of the 

This application is a continuation-in-part of U.S. patent "world" considered in arriving at the decision. For cxanaple. 

Ser. No. 09/092348. filed Jun. 5, 1998 now U.S. Pat No. the decision being made may be how much of a given item 

6.119,149. This application is related to U.S. patent appli- a factory should produce during a given time period. The 

cation Ser. No. 09/156,722, entided, "System and Method lo "optimal" answer depends on the domain of the decision, 

for Creating an Object Workspace;" U.S. patent appUcatioo The domain may be, for example, just the factory itself, the 

Ser. No. 09/156,265 entitled, "System and Method for supply chain that contains the factory, the entire enterprise, 

Remotely Accessing Data;" U.S. patent appUcation Ser. No. or the multi-enterprise supply chain. (The latter two can be 

09/156,264, entitled "Workflow Communication;" U.S. considered to be larger domains or multiple domains.) 

patent application Ser. No. 09/156^33, entitled, "Workflow i5 Typically, the larger the domain of the decision support, the 

Synchronization;" U.S. patent application Ser. No. 09/156, more optimal the decision wiU be. Consequently, it is 

342. entitled. "System and Method for Event Notification desirable for decision support software to cover ever larger 

Through a FirewaU;" U.S. patent application Scr. No. domains in die decision making process. Yet. this broaden- 

09/154,661, entided "Object-Oriented Workflow for Enter- ing of coverage can create significant problems, 

prise Collaboration;" and U.S. patent appUcaUon Ser. No. 20 oitx4a>iadv r^T: ttjx: TWPNmnM 

09/156,334, enUUed, "Method and System for Managing SUMMARY OF THE INVENTION 

CoUaboraUon Within and Between Enterprises;" all filed accordance with the present invention, an exemplar 

Sep. 18, 1998, the disclosures of which are incorporated by workflow used for the design and deployment of a workflow 

reference herein. for enterprise collaboration is disclosed that provides advan- 

TECHNICAL FIELD OF THE INVENTION conventional supply chain, enterprise and site 

^ „ , , , , planning environments. 

This invention relates in general to the field of supply ^ * * * *u 

xuio ixi V 6 rr j According to one aspect of the present mvention, an 

cham,enterpnseandsue P^^^^S ^^1' P^^^^^ exemplar workflow isXlosed for ise in the design and 

an exemplar workflow used for the design and deployment ^^^J ^ ^^^^^^ fo, rise collaboration. A 

of a workflow for enterprise coUaboraUon. 30 ^^^^^^^^ implemented process involves allowing a work- 

BACKGROUND OF THE INVENTION flow design to include at least one exemplar workflow. The 

Supply chain, enterprise and site plamiing applications exemplar workflow is associated with an exemplar node 

and environments are widely used by manufacturing entities aUowing at least one acUvity to be parametenzcd over a 

for decision support and to help manage operations. Deci- 3s ?^''''^^y nodes wittun a node group. The process then 

sion support environments for supply chain, enterprise, and ^ivolves mstanliaUng the workflow such that at least one 

site plaining have evolved from single^domain, monolithic exemplar workflow is mstanUated as a plurahty of activities 

environments to multi-domain, monoUthic environments. each associated with a specific node m the node group. T^e 

Conventional planning software applications are available in workflow is deployed by distnbuUng the acUviUes over the 

a wide range of products offered by various companies. 40 nodes in the node group lo provide mulu -enterprise coUabo- 

Thesc decision support tools allow entities to more efifi- ratton. 

ciently manage complex manufacturing operations. A technical advantage of the present invention is the 

However, supply chains are generally characterized by ability to design, instantiate, deploy, execute, monitor and 

multiple, distributed and heterogenous planning environ- modify sophisticated multi-enterprise collaborations using 

ments. TTius, there are limits to the effectiveness of conven- 45 an exemplar workflow for a group of related nodes, 

lional environments when appUed to the problem of supply Additional technical advantages should be readily appar- 

chain planning due to monolithic application architectures. cnt to one skilled in the art firom the following figures. 

Further, these problems are exacerbated when there is no one descriptions, and claims, 
"owner" of the entire supply chain. 

It is desirable for the next evolutionary step for planning 50 BRIEF DESCRIPTION OF THE DRAWINGS 

environmenu to establish a muld-domain, heterogenous a more complete understanding of the present invention 

architecture that supports products spanning multiple advantages thereof may be acquired by referring to the 

domains, as well as spanning multiple engines and products. following description taken in conjunction with the accom- 

Thc integration of the various plarining environments into a panying drawings, in which like reference numbers indicate 

seamless solution can enable inter-domain and inter- 55 like features and wherein* 

enterprise supply chain planning. Further, an important ' " ^^bodiment of a computer 
function provide^ by some planmi« apphcal^ons ^^e ^ arch^cture that can support enterprise'^col- 
Optimization of the subject environment rather than simply 1 t; ^• 
u■acking transactions. In particular, the RHYTHM family of ^ ^- r , r 
products available from 12 TECHNOLOGIES provide opU- so ^IG. 2 is a diagram of one embodunent of components of 
mization functionaUty. However, with re^ to planning at a global collaboration framework; 

the enterprise or supply chain level, many conventional FIG. 3 is a diagram of the global collaboration framework 

applications, such as those available from SAP, use enter- of FIG. 2 where certain software elements that make up 

prise resource planning (ERP) engines and do not provide particular modules arc highlighted; 

optimization. 65 FIG. 4 is a block diagram of one embodiment of a system 

The success or failure of an enterprise can depend to a allowing collaboration within and between enterprises for 
large extent on the quality of decision making within the optimal decision making 
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FIG. 5 is a block diagram of one embodimenl of the use laboratioa. As shown, a global decision support architecture 

of a global collaboration workspace; can be built upon underlying link, vision, global messaging 

FIG. 6 is a diagram of one embodiment of a lifecycle for and data warehouse components. Collaboration can then 

a collaboration* involve a global collaboration designer (GCD) and a global 

„^ „ . f • . L r*. 5 colIaboratioQ manager (GCM) supported by the decision 

FIG. 7 IS a diagram of situations where common software ^ ^ ^r™^ i i,. j • 

i_ J r 1 *• L- J u ' ^* support architecture. The global collaboration designer can 

IS present on both sides of a relationship and where it is not; ^^^PP^ ^^.^^ ^^^^^^^ coUaborations,1nd the 

FIG. 8 is a block diagram of one embodiment of a security ^^^^^^ collaboration manager can be used to run the col- 

configuraUon for a hub-to-spoke and hub-to-web case; laborations. In this scheme, collaborations can be referred to 

FIG. 9 is a block diagram of one embodiment of a security lo as modules and can be versioned. 

configuration for a hub-to-hub case; FIG. 2 is a diagram of one embodiment of components of 

FIG. 10 is a diagram of one embodiment of designing an a global collaboration framework. As shown, the framework 

inter-enterprise workflow that includes parameterization can allow an hub enterprise 2 to collaborate with a spoke 

over groups; enterprise 4 and a web enterprise 6. Hub enterprise 2 and 

FIG U is a diagram of one embodiment of managing 15 spoke enterprise 4 each include a gbbal coUaboration man- 
change be modifying a design of a workflow; ager 8. Global coUaboration managers 8 are coupled to and 
If A Jim J- c A' communicate with respective internal global collaboration 

FIGS. llAand IIB are a diagrams of another embodi- . . / i i l i nT j 

.... . . ° ufl™ »u,f -^^i,.^-. workspaces 10. An external global coUaboraUon workspace 

ment of designmg an mtcr-cnterpnsc workflow that mcludes ^^^^^ ^ shan^gdata between hub enterprise 

parameterization over groups; spoke enterprise 4 and web enterprise 6. Hub enterprise 2 

FIG. 12 is a diagram of one embodunent of mtegration of ^ coUaborate through an electronic data interchange 

a workflow with the outside world; ^^^^ processor 14 with a value added network (VAN)- 

FIG. 13 is a diagram of one embodiment of a data flow Further, hub enterprise 2 can communicate and collaborate 

running in a single activity; with other hub enterprises using a global message bus 15. 

FIG. 14 is a diagram of one embodimenl of a data flow 25 In operation, the primary controller of the collaboration 

split across multiple activities; can be the GCM engine 8 of hub enterprise 2. The hub-to- 

FIG. 15 is a block diagram of one embodimenl of an hub relationship can be fadUtated by the global message bus 

common data model based transformation model; 15, and the hub-to-spoke and hub-to-web relaUonships can 

™„ . c . . ^ be facilitated by external global coUaboration workspace 

FIG. 16 is a diaEram of one embodiment or a direct ^^„,r^ ^^ t 

rivj. xu K> a uia^aiii kjl vju ixjw (GCW) 12. As shown, a hub enterprise 2 can generaUy have 

Uransformation; internal GCW 10 and an external GCW 12. Internal GCW 

FIG. 17 is a diagram of one embodunent of different ^ ^^^^ exchange data with internal user 

access and transformation levels; and interfaces as well as EDI processor 14. External GCW 12 

FIG. 18 is a diagram of one embodiment of substituting can be used to share and exchange data with spoke enter- 

a hub engine for a ^ke engine within a collaboration. 35 prises 4 and web enterprises. 

DETAILED DESCRIFTON OF THE ^"^''y- c=m be instaUed in a DMZ 

INVENTION outside a corporate firewaU of hub enterprise 2. This way 

no direct connections need to be made from the outside into 

Improvement of decision support processes involves the protected corporate network of hub enterprise 2. External 
expansion to provide enterprise level and multi-enterprise 40 GCW can accept, for example, HOP, HTTP and HTTPS 
level decision support for optimal decision making. Tech- connections. In particular, the latter two connections are 
nologicaUy and conceptually, providing enterprise-level and useful for bridging existing flrewaU configurations. In this 
multi-enterprise level decision support differs from provid- manner, no firewaU configuration is needed on either the 
ing factory-level and supply-chain-level decision support. client (spoke node or web node) or server (hub node) side 
The reasons for this can be that, in multi-domain situations 45 which can make the solution more quickly deployable. 
(such as business units within an enterprise or multiple FIG. 3 is a diagram ofthe global collaboration framework 
enterprises), the different domains often operate different of FIG. 2 where certain software elements that make up 
decision support software. Also, in multi-domain situations, particular modules are highlighted. As can be seen, software 
one domain generally can not coerce another domain into for the global coUaboration manager module can be present 
making a particular decision. In other words, optimal deci- 50 in the foUowing places: in the hub engine 8, in the spoke 
sion support in this environment often needs to be performed engine 8, in the hub-user user interface (UI), in the spoke- 
in a negotiated, as opposed to coercive, environment user UI and in the web-node UI. Additionally, the module 

Providing decision support in multi-domain situations can can communicate with native applications 17 on the hub 

be accomplished by pursuing a collaborative approach to enterprise 2 and spoke enterprise 4. Communications with 

decision support rather than a coercive one. Various com- 55 native applications 17 can be either synchronous (dot line) 

municatioD and distributed processing technologies can be or asynchronous (solid line). Asynchronous communication 

used to implement such an environment, including the with native applications 17 can be facilitated by the internal 

Internet, the Web, JAVA, XML, CORBA, etc., which help GCW*s 10, as shown. Further, a global series database 

make large scale coUaborative decision making feasible. (GSDB) can be present on the hub enterprise 2 side. 

Products wiU soon be avaUable from 12 TECHNOLOGIES 60 FIG. 4 is a block diagram of one embodiment of a system, 

that enable a collaborative approach to decision support, indicated generaUy at 16, aUowing collaboration within and 

including RHYTHM-GLOBAL COLLABORATION between enterprises for optimal decision making. As shown, 

MANAGER (GCM) and RHYTHM-GLOBAL COLLABO- system 16 includes a hub node 18 which can be a process 

RATION DESIGNER (GCD). within a hub engine executing on a computer system. Hub 

CoUaboration System and Process Components 65 node 18 is coupled to and commimicates with a spoke node 

FIG. 1 is a diagram of one embodimenl of a computer 20 which also can be a process within a hub engine execut- 

implemented architecture that can support enterprise col- ing on a computer system. As shown, spoke node 20 can be 
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outside an enterprise boundary 22 of hub node 18. Hub node workspace 30 stores data in the form of objects and can store 
18 is also coupled to and communicates with a plurality of Java Objects, CORBA ejects or arbitrary byte arrays. This, 
spoke nodes 24 which can be processes within a spoke coupled with its in-memory capabilities, makes global col- 
engine executing on one or mote computer systems. Hub laboration workspace 30 appropriate as a high-speed data 
node 18 can further be coupled to and communicate with a 5 sharing mechanism between other object-oriented 
plurality of web nodes 26 which can be processes within a in-memory engines such as 12 TECHNOLOGIES' SUPPLY 
web browser execuUng on a computer system. In addition. CHAIN PLANNER and EACTORY PLANNER- 
hub node 18 is coupled to and communicates with an EDI A global coUaboraUon designer (CCD) provides a tool to 
(Electronic Data Interchange) proxy 28 which can provide a aUow coUaboration designers to interactively design, instan- 
gateway to EDI systems. tiate and deploy collaborations to be run using the global 
Hub engines and spoke engines, together with a global collaboration manager. The output of the global coUabora- 
coUaboration workspace, can be the primary entities of a tion designer is code that can be automatically loaded and 
global collaboration manager. In this environment, a hub run by the global collaboration manager. The global col- 
engine is the primary controller of the coUaboration. The laboration designer can allow designers to create new 
hub engine can coordinate both global collaborations as well collaborations, retrieve existing collaborations, and version 
as local collaborations. Global collaborations are those that collaborations. The global collaboration designer can also 
span hub nodes 18, spoke nodes 20 and 24 and web nodes allow designers to design the hub and spoke network for 
26. A local coUaboration can run on any single role hub or collaborations and design the events and messages of the 
spoke/spoke group. These collaborations can be distributed, collaboration. The global coUaboration designer can inte- 
but stay within the confines of a single enterprise. Hub grate a standard object library and a standard component 
engines can also coordinate with hub-user interfaces (UI) as 20 Ubrary for easy usage from within the global coUaboraUon 
weU as the VAN-EDI processor of an EDI proxy 28. In one designer. The global collaboration designer can be used to 
embodiment, hub engines are multi-threaded engines that create sophisticated multi-enterprise workflows with 
can simultaneously coordinate multiple collaborations as synchronous, asynchronous, sub-workflow, and-splits, 
weU as multiple versions of the same coUaboration. Further, or-splits, synchronization-joins, heterocast-splits, 
the hub engines can dynamicaUy load and execute coUabo- 25 heterocast-joins etc. Global workflows and k)cal workflows 
faliojjs can both be created. The global collaboration designer can 
Aspoke engine can also operate to initiate a coUaboration. provide automatic verification of collaborations and auto- 
In this environment, unlike a hub engine, a spoke engine is matic code generation, which code is run by the global 
not an independent entity. Instead a spoke engine can only coUaboration manager. The generated code can be manuaUy 
coordinate a coUaboration in conjunction with a hub engine. 30 edited if desired. Further, the global coUaboration designer 
Furthermore, a spoke engine can not coordinate with other can provide instantiation of a collaboration including gen- 
spoke engines or other web-nodes. Like a hub engine, a eration of security manager configurations and global col- 
spoke engine can be multi-threaded and can simultaneously laboration workspace configurations, 
coordinate muUiple coUaborations as weU as multiple ver- FIG. 6 is a diagram of one embodiment of a Ufecycle for 
sions of the same collaboration. Spoke engines can also 35 a collaboration. As shown, in step, a collaboration can be 
dynamicaUy toad and execute coUaborations. designed using the global coUaboration designer. Then, in 
FIG. 5 is a block diagram of one embodiment of the use step 46, a collaboration can be instantiated using the global 
of a global coUaboration workspace 30. In HG. 5, global collaboration designer. The instantiated coUaboration can 
coUaboration workspace 30 provides the primary entity used then be deployed, in step 44, using the gtobal coUaboration 
to share data/objects between the various entities in the 40 designer and the global collaboration manager. After 
coUaboration. As shown, workspace 30 can interface with deployment, the coUaboration can be run using the global 
global coUaboration managers (GCMs) 32, a local system collaboration manager in step 46. Subsequently, a new 
34, a web server 36 and web interface 37 and native instancecanbecreatedor anew version of the coUaboration 
applications 38. In general, objects can be placed into global can ve created. To create a new instance, the flow returns to 
collaboration workspace 30 by one entity and retrieved by 45 step 42. For a new version, the global coUaboration designer 
another entity. Retrieval can be achieved either by querying can be used in step 48 to modify the coUaboration. 
or by subscription. In this way, global coUaboration work- The extension from single-domain decision support to 
space 30 combines the attributes of a database as well as a multi-domain decision support can be compUcated. In 
message bus. particular, the foUowing discussion describes a number of 
The global coUaboration workspace can be organized as 50 chaUenges presented by multi-domain decision support and 
a hierarchy of stots which can be in-memory or persistent. embodiments of how Uiose chaUenges are addressed by the 
Slots also can be queued or regular, and fine grained present system and process aUowing coUaboration within 
permissibiUties can be attached to each stot. The permissi- and between enterprises for optimal decision making, 
bilities can be assigned by-user-by-operation. The primary Representational Heterogeneity 

operations can be read, write, take, and subscribe. 55 One problem with coUaboration is bridging representa- 

In-mcmory slots hoW their data in volatile memory. tional heterogeneity across enterprises. Before coUaboration 

Writing and retrieval from in-memory slots is very fast but can successfiiUy occur, the representational heterogeneity 

subject to loss if the global coUaboration workspace 30 goes across enterprises needs to be bridged. Enterprises often 

down. When used with in-memory slots, the global coUabo- represent the same data in different ways. These differeiices 

ration work;H>aoe 30 can be considered a fast, secure, 60 range from semantic differences, to technological 

in-memory object database, with security and messaging differences, to differences in naming, etc. One obvious 

capabiUties. Persistent slots bold Uieir data in stable storage. solution to bridging these differences is standardization. 

Writing and retrieval from persistent slots is stower than Cor However, this immediately raises the issue of what standard 

in-memory slots, but data is not lost if the global coUabo- to agree upon. The present system and process avoid such a 

ration work^ace 30 goes down. 65 requirement. 

The decision as to whether to use in-memory or persistent It should be noted that there can be three relevant cat- 
slots can depend on the appUcation. Global collaboration egories of standards that need to be addressed. These three 
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categories are: format standards, transport standards and data/objects that enterprises would like to exchange. Further, 

semantic standards. Format standards refer to the techno- waiting for standards bodies to standardize on a particular 

logical formats in which the data/objects are encoded. objectmay not be an option, and a supply chain will not have 

Examples include XML, Java Serial Streams, HOP Serial any particular competitive advantage by using public stan- 

Streams and EDI format. Transport sta ndards are used to 5 dards. For these and other reasons, the present global 

pass data around. These can include HTTP, HOP, RMI, collaboration manager supports an alternative approach to 

DCOM, FTP, Value Added Networks, Asynchronous Mes- standardization by supporting proprietary community stan- 

sage Buses such as MQSeries, etc. Third, semantic standards ^or example, using RHYTHM-GCD. a community of 

are the way in which the semantic content of the data is enterprises can devise a set of standards that are relevant to 

described. Examples include EDI, 12 COMMON DATA that a>mmunity only. 

MODEL (CDM). ^.j- r RHYTHM-GCM wiU support and enforce these propri- 

By consideringstandards m this bght, an understanding of community standards. RHYTHM-GCD also supports 

±e issues can emerge. A lot of the confusion today stems ^ of builLg block objects that can be composed into 

from the fact that many exisung standards cover two or more <^^^^<^y^ e , ^, . „ • , J'^ 

of the categories above and Zi discussions of the various propnetary community standards Propnetary community 

standards fail to categorize which category is being dis- standards have a number of ac^vao^ges, mck^^^ 

cussed. For example, EDI is primarily a semantic standard, be designed to exacUy cover the kmds of data/objects that 

but also typically implies a format standard (the EDI file enterprises would hke to exchange; only the relevant parties 

format) and a transport (a Value Added Network). Once diis need to agree upon the particular standard, hence the process 

is understood, it becomes clear that the EDI semantic will be much quicker than waiting for a standards body; 

standard can be separated from the other two. Hence, 20 different standards can be developed for different categories 

semantic EDI objects can be encoded in other formats such of partners and, in the extreme case, a different standard for 

as Java Serial Streams and can be passed over other transport each partner; and standards that give the supply chain a 

standards such as HTTP. Similarly, XML is primarily a competitive advantage over competitors can be developed, 

formal standard that can be used to encode various semantic Multiple Relationship Types 

standards. Efforts are underway to encode EDI in XML. 25 Another problem for allowing collaboration is handhng 

Several format standards can be supported by the present multiple relationship types. Enterprises have rclatioiiships of 
global collaboration manager, including XML, EDI format, various types with their partners. Some ways relationships 
Java Serial Streams (referred to as Java format and not to be can vary are: between major trading partners on the one hand 
confused with the Java Language or Java Platform) and HOP and between minor trading partners on the other; between 
Serial Streams. Of these, in one embodiment, the Java 30 enterprises of roughly equal influence over the supply chain 
format is the primary format, and the rest are derived and between enterprises of unequal influence over the sup- 
formats. Because the Java Formal can contain the behavior ply chain; and between enterprises with a high degree of 
to produce the other formats, it has been chosen as the technological sophistication on the one hand and between 
primary format. XML, EDI and HOP formats can be derived enterprises with an unequal degree of technological sophis- 
from the Java Format. 35 tication on the other. As should be understood, these differ- 

FIG- 7 is a diagram of situations where common software ent relationship types should be handled differently, 

from 12 TECHNOLOGIES' is present on both sides of a The present global collaboration manager can model 

relationship and where it is not. As shown, for example, enterprise relationships as a hub and ^oke networic, as 

when RHYTHM GLOBAL COLLABORATION MAN- described above and shown in FIG. 4. In this embodiment, 

AGER is on both sides, nothing is to be gained by converting 40 the four types of relationships are: Hub-to-Web; Hub-to- 

to an intermediate format. This would introduce needless Van-EDI; Hub-to -Spoke and Hub -to -Hub. Each 

inefiBciency, and only data (not objects) would be relationship-type has its appropriate usage, 

exchangeable, limiting the range of applications. Hence With respect to Hub-to-Web, when people speak of 

when the same software is present on both sides, binary Java E-Commerce today, they often imply an architecture where 

objects can be directly exchanged On the other hand, for 45 a web browser talks to some centralized server. This archi- 

cxample, when RHYTHM GLOBAL COLLABORATION techire has some advantages: the infrastructure to support 

MANAGER is present only on one side, XML or EDI- this architecture is typically already in place; and all admiii- 

formattcd "objects" can be produced (outbound) and inter- istration can be centralized on the server side. However, this 

preted (inbound). architecture also has a big disadvantage in that it requires the 

With respect to transport standards, the present global 50 presence of a human on the web-browser side. Hence 

collaboration manager can support a variety of transport system-to-system automation is not possible. Based on these 

standards, including HTTP, HOP, and Asynchronous Mes- and other pros and cons, this relationship type can be 

sage Buses. More details are provided below with respect to appropriate when an enterprise needs to exchange data with 

Handling Multiple Relationship Types. either a minor partner or a partner with less tedinological 

Wth respect to semantic standards, the present global 55 sophistication, 

collaboration manager can primarily support two semantic With respect to Hub-to-VAN-EDI, the vast majority of 

standards, EDI and RHYTHM-CDM. EDI can be supported electronic inter-cnterprisc commerce takes place today by 

because it is gcneraUy the most popular semantic standard. sending EDI over Value Added Networks. The advantage of 

However it suffers from the drawback (amongst others) of this approach can be that system-to-system integration is 

not providing deep coverage of the planning domain. The 60 possible and it is currently supported today. Disadvantages 

RHYTHM-CDM, on the other hand, provides deep coverage of this approach are: large costs to send data over proprietary 

of the planning domain and will provide appropriate con- VAN's; high administrative costs because of lack of true 

structs for performing multi-enterprise decision support. standardization; requirement for third party tools just to 

Additionally, this format is supported by all of 12 TECH- convert from the true "standard" to a form appropriate for 

NOLOGIES' planning engines. 65 the enterprise; no support for system-to-human integration; 

In general, one problem with pubUc standards, such as and no support for proprietary standards or corporate stan- 
EDI, is that they may not adequately cover the kinds of dards. Based on these and other pros and cons, this rela- 
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tionship type can be appropriate when supporting a legacy 
VAN-EDI environment. 

With respect to hub-to-spoke, this relationship type also 
enables system-to-system integration like VAN-EDI. Archi- 
tecturally hub-to-spoke is a collaboration between a hub 
engine and a spoke engine. The hub-to-spoke relationship 
can have advantages vis-a-vis VAN-EDI: it can use the 
public Internet to reduce network costs; administrative costs 
are much lower than VAN-EDI because a large portion of the 
hub-to-spoke relationship infrastructure can be centrally 
deployed and administered; true objects (in addition to just 
data) can be exchanged allowing for much more advanced 
collaborations; and multiple semantic standards can be sup- 
ported including EDI, I2-CDM and Proprietary Community 
Standards. Based on the characteristics above, the hub-to- 
spoke relationship can be appropriate between enterprises 
that wish to perform sophisticated system-to-system col- 
laboration. It can also be appropriate where no 12 TECH- 
NOLOGIES' software is present in either of the enterprises. 
This is because the hub-to-spoke relationship can be cen- 
trally deployed by the hub enterprise. 

Wth respect to hub-to-hub, the relationship is similar to 
hub-to-spoke except that it takes place between two hub 
engines rather than a hub and a spoke engine. Based on this 
characteristic, the hub-to-hub relationship can be appropri- 
ate between enterprises that wish to perform sophisticated 
system-to-system collaboration. Further, the hub-to-hub 
relationship can be appropriate when two enterprises have 
individually and separately purchased RHYTHM-GCM and 
have set up hub engines. 

There are differences between hub engines and spoke 
engines. In general, a bub engine's capabilities are a superset 
of a spoke engine's capabilities. The following table pro- 
vides an example of some of the differences. 



TABLE 1 




Spoke Engine 


Hub Engine 


Purchasing and 


Spoke engines are 


Sold separately. 


Deployment 


bundled with a hub 
engine. Hence a hub 
entaprisc will 
typically poichase a 
hub eng^ie and a 
number of ^kc 
engines which it can 
deploy out to its 
partners. 




Relationship 


Can only support the 


Supports 


types st^ported 


hub-to-8poke 


bub-to-hub. 


relationship. 


hub-to-spokc. 




Additionally, each 


hid}-u>-web and 




spoke engine can 


hub-to-VAN-EDI 




only cominunicate 


relationship 




with a particular 


types. 




hub engine (its 






owning hub). 




Authoring 


Can view but not 


Can view and 


CollaboratioDs 


author a 


author a 




collaboration. 


collaboration. 


Intcraal-Uscr 


Supports a single 


Supports multiple 


Roles. 


internal-user role. 


internal- user 
roles. 
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include that: data exchanged between two partners should 
only be seen by the two partners; data exchanged between 
two partners should be tampcr-proofc an enterprise should be 
able to verify that a partner is who it claims to be; the 
framework should not introduce new security holes into a 
partners* network; and the framework should be relatively 
easy to set up and administer. 

A secure collaborative framework can be provided by 
implementing a comprehensive security strategy to address 
the above requirements. In one embodiment, the strategy has 
three different aspects to it: technological security, a per- 
missibility framework and data partitioning. 

Technological security can refer to the technological 
means used to guarantee security. This security can be used 
to provide: privacy, authentication and data integrity. Pri- 
vacy ensures that no unauthorized person can see the data. 
Authentication involves authenticating that the parties in the 
collaboration are really who they claim to be. Data Integrity 
involves making it impossible for an unauthorized person to 
modify data being sent in any fashion. 

The precise security approach can vary based on the 
relationship type described earlier. For example, one scheme 
is detailed in the table below: 

TABLE 2 



Relationship 


Tbchnologtcal 




Type 


Approach 


Provided By 


Hub-to-web 


HTTP-over-SSL 3.0 


Global Collab 






Workspace 




Diffie-Hclman) 






HTTP-over-SSL 3.0 






(e.g. RSA) 






nOPK)ver-SSL 3.0 


Global Collab 
Workspace 


Hub-to-spokc 


HTTP-ovci-SSL 3.0 


Global Cbllab 






Workspace 




Oif&e-Helman) 






HTTP-ovci-SSL 3.0 


Global Collab 




(e.g.. RSA) 


Workspace 




nOP-over-SSL 3.0 


Global Collab 
Workspace 


Hub-to-hub 


TCP/IP-ovcr-SSL 


Global Message 




3.0 


Bus 




Cbntent-based 


Global Message 




Encryption 


Bus 


Hub-to-VAN EDI 


Security bandied 
by VAN. 


VAN 



Security 

A further problem with collaboration is the challenge of 
providing comprehensive security. Before enterprises can 
collaborate effectively, the security issue needs to be 
addressed. Tbere are many different facets to security in a 
collaborative context. Any multi-enterprise collaborative 
framework should address all of these different facets. The 
requirements for a collaborative security framework can 



60 



As can be seen from the table, all of the relationship types, 
with the exception of Hub-to-VAN EDI, could support 
security via SSL 3.0. 

SSL 3.0 is an industry standard protocol used to support 
public key encryption over a socket-based connection and 
provides: privacy, client as well as server authentication, 
data integrity and certificate management. SSL 3.0 is a 
higher level protocol into which several public-key cryp- 
tography algorithms can be plugged including RSA and 
Diffie-Helman. 

Once the SSL handshake is complete, the next step is 
uscmame-password authentication. This provides authenti- 
cation beyond what SSL 3.0 itself provides. Passwords can 
be stored using PKCS5 password-based encryption (an RSA 
standard). Once a user or spoke is authenticated, it is 
returned an Access Token. This access token has an 
administrator-specifiable lifetime. A user can then access the 
system for the duration of validity of the access token. This 
has the beneficial effect of not requiring authentication on 
each access. Each application which is accessed, authenti- 
cates the access token by validating the signature (which is 
a digest encrypted using the Security Manager's private key) 
of the Sectirity Manager. 
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The technological security framework is a portioo of the 
security scheme. The other portion has to do with the design 
of the collaborations themselves. The framework should 
allow enterprises to easily attach permissibilities to various 
actions that other enterprises can perform on it. The global 
collaboration workspace can support a hierarchical permis- 
sibility model with individual permissibilities attached to 
different data elements in the hierarchy. In particular, it can 
support user-specific and spoke -specific read, write, take and 
subscribe permissibilities. Hence, enterprises can finely tune 
who can read what data, who can write what data, who can 
take what data and who can subscribe to write-notifications 
on what data. 

A third element in the collaboration framework security 
strategy is the ability to partition data across various col- 
laborative workspaces. In particular, the collaborative work- 
spaces are split into an internal collaborative workspace and 
an external collaborative workspace. Only data that needs to 
be truly shared with partners is in the external collaborative 
workspace. The rest is in the internal collaborative work- 
space. The external collaborative workspace is designed to 
sit either outside the corporate firewall or in an Extranet or 
DMZ. The collaboration framework design does not require 
the external collaborative workspace to make connections 
through the corporate firewall into the Intranet (although it 
could). 

In one embodiment, global collaborations can use both 
the external and internal collaborative workspaces. Local 
collaborations can use only the internal collaborative work- 
space and are hence completely invisible to partner enter- 
prises. Even for global collaborations only the relevant 
portions use the external collaborative workspace. 
Furthermore, because of the permissibility framework 
described earlier, each partner enterprise can only see (read, 
write, take, subscribe) to its own data. 

FIG. 8 is a block diagram of one embodiment of a security 
configuration for a hub-to-spokc and hub-to-web case. As 
shown, a hub enterprise 50 is coupled to and communicates 
with an internal global collaboration workspace 52 and an 
external global collaboration workspace 54. A spoke enter- 
prise 56 and a web enterprise 58 connect through a web 
server 60 to the external global collaboration workspace 54. 
Spoke enterprise 56, like hub enterprise 50^ has an internal 
global collaboration workspace 62. The enterprises 50, 56 
and 58 can be protected by associated firewalls, while the 
extranet formed by web server 60 and external global 
collaboration workspace 54 can be protected by a filtering 
router and communication via HTTP over SSL 3.0. 

FIG. 9 is a block diagram of one embodiment of a security 
configuration for a hub-to-hub case. As shown, a hub 
enterprise 64 and a hub enterprise 66 can communicate 
across an SSL 3.0 protected TCP/IP connection. The com- 
munication can be between separate global message brokers 
68 and 69. Both hub enterprises 64 and 66 are protected by 
a firewall, as shown. 
Intcr-Entcrprise Workflows 

One of the problems with multi-enterprise decision sup- 
port can be that there is no closed loop collaboration. 
Instead, data may be lobbed from one enterprise to the next 
with no coherent workflow. In order to implement closed 
loop collaboration, support for creating multi-enterprise 
workflows is necessary. The present global collaboration 
manager and designer can make it possible to construct, 
deploy, monitor and change sophisticated multi-enterprise 
workflows. 

In general, a "workflow** can be a set of "activities** joined 
together by data flows that together accomplish some task. 
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Workflows are typically executed on workflow engines. A 
"distributed workflow** can refer to a workflow that is 
executed on multiple workflow engines. In other words, 
different portions of the workflow execute on different 

5 engines. A "node" can refer to the abstract entities on which 
different workflow engines of a distributed workflow run, 
and a "node group** can be a set of nodes grouped by some 
characteristic. A "multi-enterprise distributed workflow** can 
be distributed workflows where the nodes are enterprises. 

10 Parameterization of workflows can be important for enter- 
prise collaboration. A "parametric workflow** is a workflow 
that is parameterized over some variable and can be regular 
or distributed. Instantiating the parametric workflow with 
different values of the parameter variable(s) produces dif- 

15 ferent instances of the workflow. A "distributed workflow 
parameterized over nodes in a node group" can refer to 
distributed workflows where the parameters of the workflow 
are the nodes in a node group. Hence, when the workflow is 
instantiated it is tailored to a particular node in a node group. 

20 There are several important features to the workflows that 
can be supported by the present global coUaboration. These 
workflows can be strongly typed. Strong typing can be 
essential in producing robust, error-free workflows. In 
essence, strong typing guarantees the type of a message at 

25 design time. For example, if the workflow is designed to 
send a Bill of Materials, then strong typing ensures that it is 
physically impossible that an object other than a BiU of 
Material is sent. For a workflow designed with the global 
collaboration designer and executed with the global coUabo- 

30 ration manager, it can be made impossible to even send an 
object of an incorrect type. This capabihty is important to 
producing robust, error-free workflows. 

Despite strong typing, there are, for example, two sce- 
narios in which wrong object types could conceivably be 

35 passed in the workflow: due to an error on the workflow 
designer's part; and a malicious attempt by someone to 
undermine the workflow. Both of these scenarios can be 
handled. The first can be handled by making it impossible 
for an error in design to lead to such a scenario. The second 

40 can be handled by making the data flows tamper-proof by 
using pubhc key cryptography or other encryption scheme 
(integrity diaracteristic) as described above. 

Another important feature is support for workflows 
parameterized over groups. Some multi-enterprise work- 

45 flows involve a large number of enterprises. In such cases it 
can become impractical to create individualized workflows 
for each partner. Instead it can be advantageous to create 
workflows that are parameterized over groups of partners. 
For example, in the realm of procurement, two groups may 

50 be primary suppliers and secondary suppliers. The primary 
suppliers group could have one type of workflow, and the 
secondary suppliers group could have another type of work- 
flow. Group-based workflows can be parametric in the sense 
that, at run time, an actual workflow can be created ^ecific 

55 to a member of a group. 

In the multi-enterprise context, an enterprise may 
collaborate, for example, with potentially hundreds or thou- 
sands of other enterprises. Each collaboration or multi- 
enterprise workflow can be potentially (and typically) 

60 unique. However, designing thousands of specialized work- 
flows with an enterprises' partners is neither desirable nor 
feasible. On the other hand, many of these workflows are 
simply parametric variations on an underlying parameter- 
ized workflow. For example, a company A may be coUabo- 

65 rating (on sales) with retailers, distributors, direct sales etc. 
Hence, it makes sense to group the various partners. An 
example grouping may be: WalMart; Scars; Rest of Retailers 
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besides WalMarl and Sears (group); Primary Distributors parameterization over groups. As has been described above, 

(group) and Secondary Distributors (group). Now, the work- a hub node 170 can be coupled to spoke nodes 172 and web 

flows with all the members, for example, of the primary nodes 174. In addition, hub node 170 can be coupled to a 

distributors group are variations on an underlying parametric spoke group 176 and a web group 178. In general, ^oke 

distributed workflow, parameterized over the particular dis- 5 group 176 comprises a collection of related spoke nodes, and 

tributor in that group. web group 178 comprises a collection of related web nodes. 

Workflows parameterized over groups can be supported As mentioned above, in designing a workflow that 

by a HETEROCASTING workflow definition technique. executes on multiple nodes within spoke group 176 or web 

The HETEROCASTING definition technique generally group 178, the problem arises how to design for the separate 

involves using a parameterized workflow definition to lo nodeswithinthegroup.lt is a disadvantage for a designer to 

instantiate heterogeneous workflows based upon differences be forced to design workflow activities specific to node. This 

in the parameters. Thus, the HETEROCASTING definition can be time consuming and inflexible. It is better to provide 

technique allows a non-parametric distributed workflow to the designer with an ability to parameterize over the node 

be easily (through a visual design tool) be made parametric group and treat the nodes more generally with respect to 

over nodes in a node group. There can be two primary is common characteristics. The HETEROCASTING workflow 

workflow activities used to accomplish this definition: a definition technique construct described above provides one 

HETEROCAST split activity and HETEROCAST join solution to this problem and allows parameterization over a 

activity. All activities between a HETEROCAST split and a node group. 

HETEROCAST join are parameterized over the nodes of a According to the present invention, an exemplar work- 
node group that these activities correspond to. 20 flow provides another solution to parameterization over 

FIG. 10 is a diagram of one embodiment of designing an nodes and can be used in the design and deployment of a 
inter-enterprise workflow that includes parameterization workflow for enterprise collaboration. The exemplar work- 
over groups. As shown, the workflow can begin vAth a flow allows a designer to design a workflow as if the 
listening activity 70 that waits for some event. Activity 70 workflow is crossing over a single node (the exemplar node) 
can be linked to parallel activity ^lit 71 that links to a 25 in a node group. At run time or deployment, actual nodes in 
sub-workflow 72 and to a hctcrocast split 73. Sub-workflow the node group can then be substituted for the exemplar node 
72, itself, can include a workflow definition. With respect to when the workflow is instantiated, deployed and executed. 
HETEROCASTING, the workflow after heterocast split 73 One embodiment of the use of an exemplar workflow in 
then becomes parameterized. Thus, in the example of FIG, the design and deployment of a workflow is shown in FIG. 
10, activity 74 is a parameterized activity. After activity 74, 30 UB, An example workflow design, indicated generally at 
a heterocast join 75 receives flow from activity 74. Sub- 180, can include a first activity 182 that is to be executed on 
workflow 72 and heterocast join 75 are finked to a synchro- a specified hub node. Next, workflow design 180 includes an 
nous or asynchronous join 76 which, in mm, Links to an activity 184 that is to be executed on nodes within a ^oke 
integrated event 77 (e.g., multicasting). A workflow like that group. In workflow design 180, activity 184 is designed 
of FIG. 10 can be designed using the present global col- 35 using an exemplar workflow that represents execution of 
laboration designer and can allow full representation of activity 184 on an exemplar node. The exemplar node 
workflow for inter-enterprise decision support. This work- generically represents nodes within the spoke group. Work- 
flow can then be instantiated and implemented through the flow design 180 further includes an activity 186 which is to 
present global collaboration manager. be executed on the hub node. As an exemplar, activity 184 

FIG. 11 is a diagram of one embodiment of managing 40 appears in workflow design 180 to be associated with a 
change by modifying a design of a workflow. As shown, an single node. However; activity 184 is parameterized over 
initial workflow design can have an event 70 Linked to a nodes in the ^ke group and can be instantiated, depbyed 
parallel activity split 71. Between activity split 71 and a join and executed with respect to two or more nodes within the 
76, there can be, for example, two activities 78. This work node group. This provides a workflow designer with sig- 
flow, once designed, can be instantiated and implemented 45 nificant flcxibihty in the design and modification of work- 
using the global collaboration manager. If a change needs to flows that distribute similar activities across related nodes, 
be made to the wodtflow, the global collaboration designer As shown in FIG. IIB, a workflow deployment 188 
greatly alleviates the trouble of making the change. For generated from workflow design 180 has activities that 
example, a new activity 79 can be added between spHt 71 match to the activities in workflow design 180. In workflow 
and join 76. The workflow can then be centrally reinstanti- 50 deployment 188, an activity 190 is deployed to the hub node 
ated and implemented. based upon activity 180 defined in design workflow 180. A 

In particular, the HETEROCAST technique can allow the plurality of activities 192 are deployed to spoke nodes (1 to 
construction of distributed workflows parameterized over N) in the spoke group based upon exemplar workflow 
nodes in a node group. This can allow a huge productivity activity 184. When created and deployed, each activity 192 
gain over designing individual workflows for individual 55 is made ^cific to its associated node. Workflow deploy- 
group members. Further, this technique makes rapid design mcnt further includes an activity 194 deployed to the hub 
and prototyping of sophisticated inter-cnterprise workflows node based upon activity 186 in workflow design 180. 
with hundreds or thousands of partners feasible. The tech- In this marmer, the workflow design can represent nodes 
nique should be distinguished from conventional "multicast- in a spoke/web group as a single node (exemplar node) yet 
ing" in which identical messages are sent out to the various 60 treat the exemplar node as more than one node during the 
nodes (partners). In essence, multicasting allows you to deployment and execution of the workflow. Thus, during the 
design a single workflow that nms identically across mul- design stage, exemplar workflows can be designed by 
tiple nodes. This differs from the HETEROCASTING assigning activities to the exemplar node. During instantia- 
technique, where the workflows run differently based on tion and deployment, activities assigned lo the exemplar 
which node they are running across. 65 node are rephcated to the appropriate nodes in the node 

FIGS. 11 A and LIB are a diagrams of another embodi- group. Different parameters are selected at run time based 
mentof designing an intcr-cnterprisc workflow that includes upon the appropriate spoke node being instantiated. This 
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allows a designer to generate a generic or general workflow 
more easily that can be applied to numerous nodes within a 
node group. 

The exemplar workflow is advantageous in allowing 
simplicity during the design phase and multiple deployment 5 
during run time for members of the node group. For 
example, returning to FIG. UB, the hub node might be 
associated with a retail outlet, and the spoke nodes in the 
spoke group might be associated with suppliers to the retail 
outlet. In creating workflow design 180, the designer may lO 
want to execute the same or similar activity at each of the 
supplier nodes. Exemplar workflow 184 aUows the designer 
to represent these activity as an activity to be executed on a 
single exemplar node. Thus, workflow design 180 is gready 
simplified. 15 

A third important feature is support for rolc-based work- 
flows. Rolc-based workflows aUow workflows to be speci- 
fied using generic roles. This capability allows the creation 
of generic or templated workflows that can be instantiated in 
various scenarios. For example, the role types can be: 20 
partner roles, spoke roles; spoke group roles; web roles; web 
group roles; user roles. As an example of roles, partner roles 
refer to the different roles played by partners. Thus, one 
partner role in the case of procurement is primary supplier 
and secondary supplier. 25 

Rolc-based workflows can lead to the concept of three 
different phases in the design and execution of a workflow. 
The design phase is the phase in which role-based work- 
flows are defined. The instantiation phase is the phase in 
which roles are mapped to instances. For example, primary 30 
supplier may be mapped to a first company, and 
PO_approver may be mapped to John Doe. Third, the nm 
lime phase can be the phase in which the instantiated 
workflow runs. 

A further important feature is the integration of automated 35 
workflows with user-oriented workflows^ Workflows can 
oflen be described as having two varieties: automated 
system-to-systcm workflows, and user interface woricflows. 
While there are workflows that are completely automated, 
and there are workflows that are completely user driven, 40 
most workflows have automated as weU as user interface 
elements. The present global collaboration noaiuger and 
designer do not need to make this artificial distinction 
between workflow types. Hence, the woricflows can be 
automated in parts and interact with users in other parts. 45 
Both the automated parts and user parts can multiple 
enterprises. 

Integration with Outside World 

FIG. 12 is a diagram of one embodiment of integration of 
a workflow with the outside world. As described in the 50 
previous section, sophisticated inter- and intra-enterprise 
workflows can be created. These workflows can be com- 
posed of activities strung together in various configurations. 
There is no restriction on what the different activities of the 
workflow can do, yet one of the major tasks of these 55 
activities is to integrate with the outside world. FIG. 12 
shows how a workflow can be integrated with the outside 
world using a component-based approach to integration. The 
components can include accessors 80, transformations 82, 
transfer objects 84, adaptors and flows 86. 60 

The global collaboration manager can support a 
component-based integration model. The component-based 
integration model allows flexibility in structuring the inte- 
gration. There can be two types of components: primitive 
components and compound components. Primitive compo- 65 
nents can include accessors 80, transformers 82 and transfer 
objects 84. Compound components include adaptors and 
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flows 86. Compound components are built in terms of 
primitive components. In this scheme, accessors 80 are used 
to access an external source such as SCP (SUPPLY CHAIN 
PLANNER), SAP, a relational database, web servers, emafl, 
message buses etc. Accessors 80 can be used to read, write 
or listen to sources and destinations of data. Transformers 82 
can be used to transform data from one form to another form. 
Transfer Objects 84 are objects that can be passed from 
activity to activity or from enterprise to enterprise. Transfer 
objects 84 can be optionally convertible to EDI, XML, 
CORBA structures etc. Accessors 80 and Transformers 82 
can be strung together to form flows. An entire flow can be 
executed in a single activity as shown in FIG. 13. 

FIG. 13 is a diagram of one embodiment of a data flow 
running in a single activity 92, As shown, a data source 90 
can be accessible &om and provide data to an accessor 
component 94. Accessor component 94 then can pass data 
through transformer components 96 and 98 which provide 
data to a second accessor component 100. Data can then be 
stored in a data destination 102. 

FIG. 14 is a diagram of one embodiment of a data flow 
split across multiple activities 104 and 106. As shown, the 
flow of FIG. 14 differs from that of FIG. 13 in that 
transformer components 96 and 98 are within separate 
activities 104 and 106 and communicate by a transfer object. 
Multi-enterprise data flows can be based on the model of 
FIG. 14 rather than that of FIG. 13. 

With respect to transformations, in one embodiment, two 
fundamental transformation types can be supported: 
I2-CDM based transformations and direct transformations. 
I2-CDM based transformations are based on 12 TECH- 
NOLOGIES' COMMON DATA MODEL (CDM). The 
CDM is an abstract schema that is available in both rela- 
tional and object forms. 

FIG. 15 is a block diagram of one embodiment of an 
I2-CDM based transformation model. As shown, transform- 
ers and accessors can be coupled to transform a application 
data into a CDM data object 110 and vice versa. For 
example, a SUPPLY CHAIN PLANNER (SCP) object 112 
can be created by an SCP accessor from SCP data 114. SCP 
object 112 can then be transformed by an SCP-CDM trans- 
former into a CDM object 110. Analogously, an SAP object 
116 can be created by an SAP accessor from SAP data 118. 
SAP object 116 can then be transformed by an SAP-CDM 
transformer into a CDM object 110. The SAP accessor and 
transformer, as with other accessors and transformers, can be 
combined into a standard SAP-CDM adapter 120 that can be 
used for CDM-based transformations other components. As 
another example, a BAAN object 122 can be created by a 
BAAN accessor from BAAN data 124. BAAN object 122 
can then be transformed into a CDM object HO by a 
BAAN-CDM transformer. These transforms work in the 
other direction as well. 

FIG. 16 is a diagram of one embodiment of a direct 
transformation. In direct transformers^ objects are converted 
from one form to another without passing through an 
intermediate format. For example, as shown in FIG. 16, 
SUPPLY CHAIN PLANNER (SCP) data 130 can be 
accessed by an SCP accessor to create an SCP object 132. 
SCP object 132 can then be directly transformed to a 
FACTORY PLANNER (FP) object 134. FP object 134 can 
then become FP data 136 through an FP accessor. This data 
flow can operate in the other direction as weU. 

In these processes, there are various levels of granularity 
at which access and transformation can take place including 
the relational (table), generic object (tree, graph, matrix etc.) 
and specific object (BiU of Material, Plan etc.) levels. 
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Sometimes access may only be available ai one level (say 
tables), but transformation may be more appropriate at 
another level (say generic object). For example, hierarchical 
aggregation (a form of transformation) is often appropriate 
on a tree object. However, the data may only be accessible 5 
in a tabular form. In this case, for example, the data should 
be accessed at the tabular level, transformed into a tree, and 
then have the hierarchical aggregation applied to it. 

FIG. 17 is a diagram of one embodiment of different 
access and transformation levels. As shown, access and lO 
transformation can have three levels. A first level 140 can 
involve table access and transforms. A second level 142 can 
involve generic object (tree, graph, etc.) access and 
transforms, and a third level can involve specific object (Bill 
of Materials (BOM), plan, etc.) access and transforms. In 15 
additional to transforms between application formats, there 
can also be transforms between the three levels, as shown. 
Deployment of Collaborations 

One important factor in a multi-enterprise collaboration 
system is the ease with which the collaboration can be 20 
deployed- As discussed, the present global collaboration 
manager can support four different kinds of partner relation- 
ships: hub-to-web, hub-to-spoke, hub-to-hub and hub-to- 
VAN-EDI. Of these four, hub-to-web has all the deployabil- 
ity characteristics of traditional web applications. Hub- to- 25 
VAN EDI can be deployable to the extent that it leverages 
an existing VAN-EDI infrastructure. While the hub-to-web 
relationship is highly deployable, it can suffer from the 
problem of requiring a human on the web side of the 
relationship. In other words, it may not be suited to system- 30 
to-system collaboration. 

Tlie hub-to-spoke solution can provide maximal deploy- 
ability in the system-to-system collaboration environment. 
In the hub-to-spoke realm, the spoke engine is analogous to 
the web browser, and the spoke portion of the collaboration 35 
is analogous to a web page or applet. Similar to a web-page 
or applet, the spoke portion of the collaboration can be 
centrally designed and deployed to the remote spoke 
engines. Unlike a web-page or applet, there may still be 
integration that needs to be done remotely. This remote 40 
integration may be unavoidable but can be circumscribed 
and precisely defined by the spoke portion of the collabo- 
ration. 

Another aspect of deployability is handling versioning. 
Collaborations once designed and deployed are likely to « 
need changing (in various different ways) as time 
progresses. It can be important that subsequent versions of 
collaborations be as easily deployable as initial versions. 
The present global collaboration manager can provide com- 
plete support for versioning and centralized redeployment of 50 
collaborations. Further, different versions of collaborations 
can be run simultaneously without impacting each other. 
This allows an existing version to be gracefully phased out 
while another version is phased in. 

Another element of the deployability of the present global 55 
collaboration manager is the leverage of existing infrastruc- 
ture. This element is evident, for example, in the support of 
the hub-to-spoke relationship over existing web protocols. 
Supporting hub-to-spoke over existing web protocols can be 
important to rapid deployment since it does not require 60 
modification or reconfiguration of an existing web infra- 
structure. A large time savings in this regard can come from 
not having to modify carefully designed firewall and secu- 
rity infrastructures that may already be in place. 
Supporting Many-To-Many Collaborations 65 

The present hub-and-spoke architecture provides easy 
manageability and deployment. However, in practice enter- 
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prises collaborate with many enterprises which in turn 
collaborate with still other enterprises. Hence, enterprises 
often form a collaborating web or graph. This can be 
supported via the abDity to substitute a hub engine for a 
spoke engine at any time. This substitution ability allows 
many-to-many collaboration webs to be grown organically 
rather than all at once. 

FIG. 18 is a diagram of one embodiment of substituting 
a hub engine for a spoke engine within a collaboration. As 
shown, an enterprise (El) may deploy a hub engine 150 on 
itself and a spoke engine 152 at all of its partner sites. In 
particular, a spoke engine 154 may be at a partner site (E2). 
If the partner site (E2) wishes to design and control its own 
collaborations, it can replace spoke engine 154 with a hub 
engine 156. From El's perspective, E2 can still be a spoke 
in El's collaboration. However, this spoke now runs on a 
hub engine 156 which can control its own collaborations 
with spoke engines 158. Further, spoke engines 160 and 162 
might be associated with a third entity (E3) that interacts 
with both hub engine 150 and hub engine 156 on behaff of 
E3. 

Extension of Framework 

An important aspect of the present framework is exten- 
sibility. Without extensibility, the framework may not be 
able to handle new situations and challenges with which it 
is confronted. There can be several different dimensions to 
this extensibility. For example, one primary area of exten- 
sibility is in the area of semantic object standards. If 
supported standards do not suffice for a particular problem, 
then the framework can be augmented with new semantic 
standards. Additionally the framework allows the building 
of proprietary semantic standards. Further, the framework 
can be extended by adding new accessors, transformers, 
adapters, etc. The standard component library can be 
extended both generally and by end-users. 

Although the present invention has been described in 
detail, it should be understood that various changes, substi- 
tutions and alterations can be made hereto without departing 
from the spirit and scope of the invention as defined by the 
appended claims. 

What is claimed is: 

1. A system providing collaboration between two or more 
enterprises, the system comprising a collaboration manager 
operable to: 

access a workflow design comprising at least one para- 
metric activity associated with one exemplar node 
generically representing a plurality of nodes within a 
node group, the parametric activity being parameter- 
ized over the nodes within the node group; 

generate a workflow according to the workflow design, 
the workflow comprising one or more generated activi- 
ties based on the parametric activity, each of the 
generated activities being executable at one of the 
nodes within the node group; and 

deploy each generated activity to a node within the node 
group at which the generated activity is executable. 

2. The system of claim 1, wherein the nodes within the 
node group arc spoke nodes. 

3. The system of claim 1, wherein the nodes within the 
node group are web nodes. 

4. The system of claim 1, wherein the parametric activity 
is immediately preceded in the workflow design by a pre- 
ceding activity executable at a hub node and immediately 
followed in the workflow design by a following activity 
executable at the hub node. 

5. The system of daim 1, wherein the generated activities 
based on the parametric activity are: 
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preceded in the workflow by a preceding activity executed 

at a bub node; 
deployed according to the preceding activity; 
executed concurrently; and 

followed in the workflow by a following activity executed 
at the hub node. 

6. The system of claim 1, wherein: 

the workflow comprises one or more hub activities 

executed at a hub node; and 
the generated activities are deployed according to at least 

one of the hub activities. 

7. The system of claim 6, wherein the hub node and the 
nodes within the node group are located within different 
enterprises. 

8. The system of claim 7, wherein the hub node is 
associated with a retail enterprise and the nodes within the 
node group are associated with supplier enterprises that 
supply the retail enterprise. 

9. A method for collaboration between two or more 
enterprises, comprising: 

accessing a workflow design comprising at least one 
parametric activity associated with one exemplar node 
generically representing a plurality of nodes within a 
node group, the parametric activity being parameter- 
ized over the nodes within the node group; 

generating a workflow according to the workflow design, 
the workflow comprising one or more generated activi- 
ties based on the parametric activity, each of the 
generated activities being executable at one of the 
nodes within the node group; and 

deploying each generated activity to a node within the 
node group at which the generated activity is execut- 
able. 

10. The method of claim 9, wherein the nodes within the 
node group are spoke nodes. 

11. The method of claim 9, wherein the nodes within the 
node group are web nodes. 

12. The method of claim 9, wherein the parametric 
activity is immediately preceded in the workflow design by 
a preceding activity executable at a hub node and immedi- 
ately followed in the workflow design by a following 
activity executable at the hub node. 

13. The method of claim 9, wherein the generated activi- 
ties based on the parametric activity are: 

preceded in the workflow by a preceding activity executed 

at a hub node; 
deployed according to the preceding activity; 
executed concurrently; and 

followed in the workflow by a following activity executed 
at the hub node. 

14. The method of claim 9, wherein: 

the workflow comprises one or more hub activities 

executed at a hub node; and 
the generated activities are deployed according to at least 

one of the hub activities. 

15. The method of claim 14, wherein the hub node and the 
nodes within the node group are located within different 
enterprises. 

16. The method of claim 15, wherein the hub node is 
associated with a retail enterprise and the nodes within the 
node group are associated with supplier enterprises that 
supply the retail enterprise. 
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17. Software for collaboration between two or more 
enterprises, the software embodied in a computer- readable 
medium and when executed operable to: 

access a workflow design comprising at least one para- 
^ metric activity associated with one exemplar node 
generically representing a plurality of nodes within a 
node group, the parametric activity being parameter- 
ized over the nodes within the node group; 
10 generate a workflow according to the workflow design, 
the workflow comprising one or more generated activi- 
ties based on the parametric activity, each of the 
generated activities being executable at one of the 
nodes within the node group; and 
^5 deploy each generated activity to a node within the node 
group at which the generated activity is executable. 

18. The software of claim 17, wherein the nodes within 
the node group arc spoke nodes. 

19. The software of claim 17, wherein the nodes within 
the node group are web nodes, 

20. The software of claim 17, wherein the parametric 
activity is immediately preceded in the workflow design by 
a preceding activity executable at a hub node and immedi- 

25 ately foUowed in the workflow design by a following 
activity executable at the hub node. 

21. The software of claim 17, wherein the generated 
activities based on the parametric activity are: 

preceded in the workflow by a preceding activity executed 
30 at a hub node; 

deployed according to the preceding activity; 
executed concurrently; and 

followed in the workflow by a following activity executed 
35 at the hub node. 

22. The software of claim 17, wherein: 

the workflow comprises one or more hub activities 

executed at a hub node; and 
the generated activities are deployed according to at least 
40 one of the hub activities. 

23. The software of claim 22, wherein the hub node and 
the nodes within the node group are located within different 
enterprises. 

24. The software of claim 23, wherein the hub node is 
associated with a retail enterprise and the nodes within the 
node group are associated with supplier enterprises supply- 
ing the retail enterprise. 

25. A system providing collaboration between two or 
more enterprises, comprising: 

means for accessing a workflow design comprising at 
least one parametric activity associated with one exem- 
plar node generically representing a plurality of nodes 
within a node group, the parametric activity being 
parameterized over the nodes within the node group; 

means for generating a workflow according to the work- 
flow design, the workflow comprising one or more 
generated activities based on the parametric activity, 
each of the generated activities being executable at one 
of the nodes within the node group; and 

means for deploying each generated activity to a node 
within the node group at which the generated activity is 
executable. 

« * « * « 
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